Add a flag to control the concurrent execution of aggregations #96023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
elasticsearchmachine
added
the
Team:Analytics
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
javanna
reviewed
May 11, 2023
test/framework/src/main/java/org/elasticsearch/search/aggregations/AggregatorTestCase.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/search/aggregations/AggregationBuilder.java
Show resolved
Hide resolved
javanna
added a commit
to javanna/elasticsearch
that referenced
this pull request
Aug 8, 2023
In elastic#98204 we are introducing unconditional offloading of collection to a separate thread pool, even for requests of phases that don't enable search concurrency. It turns out that some aggs don't support offloading their collection to a separate thread, as their postCollect method is executed on the search thread which trips a lucene assertion around reusing data structures pulled from the search worker thread. With this commit we allow aggs to specify when they don't support offloading their sequential collection. Such aggs are a subset of the ones that already declare that they don't support concurrency entirely. Relates to elastic#96023
javanna
added a commit
that referenced
this pull request
Aug 8, 2023
In #98204 we are introducing unconditional offloading of collection to a separate thread pool, even for requests of phases that don't enable search concurrency. It turns out that some aggs don't support offloading their collection to a separate thread, as their postCollect method is executed on the search thread which trips a lucene assertion around reusing data structures pulled from the search worker thread. With this commit we allow aggs to specify when they don't support offloading their sequential collection. Such aggs are a subset of the ones that already declare that they don't support concurrency entirely. Relates to #96023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial testing has shown that some aggregations are problematic when running on concurrency mode. In order to be able to run aggregations with concurrency, this PR proposes to add a flag that can tell if an aggregation block can be run concurrently. In addition it updates the
AggregationTestCaseto randomly run concurrently. This test has been used to uncover the problematic aggregations.The problematic aggregations fall into two groups:
The issue with this aggregations is that they have a post-collection phase that uses some generated data structures during the collection phase. Because this are run on different threads, we hit a lucene assertion. These aggregations are Cardinality, nested and Composite aggregations.
Label the PR as non-issue as we don't support concurrent searches.